<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!-- Copyright (c) 2000-2009  Josh Coalson -->
<!-- Copyright (c) 2011-2016  Xiph.Org Foundation -->
<!-- Permission is granted to copy, distribute and/or modify this document -->
<!-- under the terms of the GNU Free Documentation License, Version 1.1 -->
<!-- or any later version published by the Free Software Foundation; -->
<!-- with no invariant sections. -->
<!-- A copy of the license can be found at http://www.gnu.org/copyleft/fdl.html -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
	<meta name="author" content="Josh Coalson" />
	<meta name="description" content="A free, open source codec for lossless audio compression and decompression" />
	<meta name="keywords" content="free,lossless,audio,codec,encoder,decoder,compression,compressor,archival,archive,archiving,backup,music" />
	<link rel="shortcut icon" type="image/x-icon" href="favicon.ico" />
	<link rel="stylesheet" type="text/css" href="flac.css" />
	<title>FLAC - documentation</title>
</head>

<body>

<div class="logo">
	<a href="index.html"><img src="images/logo130.gif" alt="FLAC Logo" align="middle" border="0" hspace="0" /></a>
</div>

<div class="above_nav"></div>

<div class="navbar">
	&nbsp;<a href="index.html">home</a>&nbsp;&nbsp;|
	&nbsp;<a href="faq.html">faq</a>&nbsp;&nbsp;|
	&nbsp;<a href="documentation.html">documentation</a>&nbsp;&nbsp;|
	&nbsp;<a href="developers.html">developers</a>&nbsp;&nbsp;|
	&nbsp;<a href="changelog.html">changelog</a>&nbsp;&nbsp;|
	&nbsp;<a href="http://xiph.org/flac">more</a>
</div>

<div class="below_nav"></div>

<div class="box">
	<div class="box_title">
		<a name="format">format</a>
	</div>
	<div class="box_header"></div>
	<div class="box_body">
		The basic structure of a FLAC stream is:
		<ul>
			<li>The four byte string "<span class="code">fLaC</span>"</li>
			<li>The <a href="format.html#def_STREAMINFO"><span class="code">STREAMINFO</span></a> metadata block</li>
			<li>Zero or more other metadata blocks</li>
			<li>One or more audio frames</li>
		</ul>
		The first four bytes are to identify the FLAC stream.  The metadata that follows contains all the information about the stream except for the audio data itself.  After the metadata comes the encoded audio data.<br />
		<br />
		<b>METADATA</b><br />
		<br />
		FLAC defines several types of metadata blocks (see the <a href="format.html">format</a> page for the complete list).  Metadata blocks can be any length and new ones can be defined.  A decoder is allowed to skip any metadata types it does not understand.  Only one is mandatory: the <span class="code">STREAMINFO</span> block.  This block has information like the sample rate, number of channels, etc., and data that can help the decoder manage its buffers, like the minimum and maximum data rate and minimum and maximum block size.  Also included in the <span class="code">STREAMINFO</span> block is the MD5 signature of the <i>unencoded</i> audio data.  This is useful for checking an entire stream for transmission errors.<br />
		<br />
		Other blocks allow for padding, seek tables, tags, cuesheets, and application-specific data.  There are <a href="documentation_tools_flac.html"><span class="commandname">flac</span> options</a> for adding <span class="code">PADDING</span> blocks or specifying seek points.  FLAC does not require seek points for seeking but they can speed up seeks, or be used for cueing in editing applications.<br />
		<br />
		Also, if you have a need of a custom metadata block, you can define your own and request an ID <a href="id.html">here</a>.  Then you can reserve a <span class="code">PADDING</span> block of the correct size when encoding, and overwrite the padding block with your <span class="code">APPLICATION</span> block after encoding.  The resulting stream will be FLAC compatible; decoders that are aware of your metadata can use it and the rest will safely ignore it.<br />
		<br />
		<b>AUDIO DATA</b><br />
		<br />
		After the metadata comes the encoded audio data.  Audio data and metadata are not interleaved.  Like most audio codecs, FLAC splits the unencoded audio data into blocks, and encodes each block separately.  The encoded block is packed into a frame and appended to the stream.  The reference encoder uses a single block size for the whole stream but the FLAC format does not require it.<br />
		<br />
		<b>BLOCKING</b><br />
		<br />
		The block size is an important parameter to encoding.  If it is too small, the frame overhead will lower the compression.  If it is too large, the modeling stage of the compressor will not be able to generate an efficient model.  Understanding FLAC's modeling will help you to improve compression for some kinds of input by varying the block size.  In the most general case, using linear prediction on 44.1kHz audio, the optimal block size will be between 2-6 ksamples.  <span class="commandname">flac</span> defaults to a block size of 4096 in this case.  Using the fast fixed predictors, a smaller block size is usually preferable because of the smaller frame header.<br />
		<br />
		<b>INTER-CHANNEL DECORRELATION</b><br />
		<br />
		In the case of stereo input, once the data is blocked it is optionally passed through an inter-channel decorrelation stage.  The left and right channels are converted to center and side channels through the following transformation: mid = (left + right) / 2, side = left - right.  This is a lossless process, unlike joint stereo.  For normal CD audio this can result in significant extra compression.  <span class="commandname">flac</span> has two options for this: <span class="argument">-m</span> always compresses both the left-right and mid-side versions of the block and takes the smallest frame, and <span class="argument">-M</span>, which adaptively switches between left-right and mid-side.<br />
		<br />
		<b>MODELING</b><br />
		<br />
		In the next stage, the encoder tries to approximate the signal with a function in such a way that when the approximation is subtracted, the result (called the <i>residual</i>, <i>residue</i>, or <i>error</i>) requires fewer bits-per-sample to encode.  The function's parameters also have to be transmitted so they should not be so complex as to eat up the savings.  FLAC has two methods of forming approximations: 1) fitting a simple polynomial to the signal; and 2) general linear predictive coding (LPC).  I will not go into the details here, only some generalities that involve the encoding options.<br />
		<br />
		First, fixed polynomial prediction (specified with <span class="argument">-l 0</span>) is much faster, but less accurate than LPC.  The higher the maximum LPC order, the slower, but more accurate, the model will be.  However, there are diminishing returns with increasing orders.  Also, at some point (usually around order 9) the part of the encoder that guesses what is the best order to use will start to get it wrong and the compression will actually decrease slightly; at that point you will have to you will have to use the exhaustive search option <span class="argument">-e</span> to overcome this, which is significantly slower.<br />
		<br />
		Second, the parameters for the fixed predictors can be transmitted in 3 bits whereas the parameters for the LPC model depend on the bits-per-sample and LPC order.  This means the frame header length varies depending on the method and order you choose and can affect the optimal block size.<br />
		<br />
		<b>RESIDUAL CODING</b><br />
		<br />
		Once the model is generated, the encoder subracts the approximation from the original signal to get the residual (error) signal.  The error signal is then losslessly coded.  To do this, FLAC takes advantage of the fact that the error signal generally has a Laplacian (two-sided geometric) distribution, and that there are a set of special Huffman codes called Rice codes that can be used to efficiently encode these kind of signals quickly and without needing a dictionary.<br />
		<br />
		Rice coding involves finding a single parameter that matches a signal's distribution, then using that parameter to generate the codes.  As the distribution changes, the optimal parameter changes, so FLAC supports a method that allows the parameter to change as needed.  The residual can be broken into several <i>contexts</i> or <i>partitions</i>, each with it's own Rice parameter.  <span class="commandname">flac</span> allows you to specify how the partitioning is done with the <span class="argument">-r</span> option.  The residual can be broken into 2^<i>n</i> partitions, by using the option <span class="argument">-r n,n</span>.  The parameter <i>n</i> is called the <i>partition order</i>.  Furthermore, the encoder can be made to search through <i>m</i> to <i>n</i> partition orders, taking the best one, by specifying <span class="argument">-r m,n</span>.  Generally, the choice of n does not affect encoding speed but m,n does.  The larger the difference between m and n, the more time it will take the encoder to search for the best order.  The block size will also affect the optimal order.<br />
		<br />
		<b>FRAMING</b><br />
		<br />
		An audio frame is preceded by a frame header and trailed by a frame footer.  The header starts with a sync code, and contains the minimum information necessary for a decoder to play the stream, like sample rate, bits per sample, etc.  It also contains the block or sample number and an 8-bit CRC of the frame header.  The sync code, frame header CRC, and block/sample number allow resynchronization and seeking even in the absence of seek points.  The frame footer contains a 16-bit CRC of the entire encoded frame for error detection.  If the reference decoder detects a CRC error it will generate a silent block.<br />
		<br />
		<b>MISCELLANEOUS</b><br />
		<br />
		As a convenience, the reference decoder knows how to skip <a href="http://www.id3.org/">ID3v1 and ID3v2 tags</a>.  Note however that the FLAC specification does not require compliant implementations to support ID3 in any form and their use is strongly discouraged.<br />
		<br />
		<span class="commandname">flac</span> has a verify option <span class="argument">-V</span> that verifies the output while encoding.  With this option, a decoder is run in parallel to the encoder and its output is compared against the original input.  If a difference is found <span class="commandname">flac</span> will stop with an error.
	</div>
	<div class="box_footer"></div>
</div>


<div class="copyright">
	<!-- @@@ oh so hacky -->
	<table>
		<tr>
			<td align="left">
				Copyright (c) 2000-2009  Josh Coalson
				<br/>
				Copyright (c) 2011-2016  Xiph.Org Foundation
			</td>
		</tr>
	</table>
</div>

</body>
</html>
